#!/usr/bin/env python
# coding:utf-8

"""
greelet 是使用一个任务调度器和一些生成器或者协程实现协作式用户空间多线程的一种伪并发机制，即所谓的微线程。

greelet机制的主要思想是:
    生成器函数或者协程函数中的 yield 语句挂起函数的执行，直到稍后使用 next() 或 send() 操作进行恢复为止。
    可以使用一个调度器循环在一组生成器函数之间协作多个任务。
"""
"""
网络框架的几种基本的网络I/O模型：
    阻塞式单线程
        这是最基本的I/O模型，只有在处理完一个请求之后才会处理下一个请求。
        它的缺点是效能差，如果有请求阻塞住，会让服务无法继续接受请求。
        但是这种模型编写代码相对简单，在应对访问量不大的情况时是非常适合的。
    阻塞式多线程
        针对于单线程接受请求量有限的缺点，一个很自然的想法就是给每一个请求开一个线程去处理。
        这样做的好处是能够接受更多的请求，缺点是在线程产生到一定数量之后，进程之间需要大量进行切换上下文的操作，会占用CPU大量的时间，
        不过这样处理的话编写代码的难道稍高于单进程的情况。
    非阻塞式事件驱动
        为了解决多线程的问题，有一种做法是利用一个循环来检查是否有网络IO的事件发生，以便决定如何来进行处理（reactor设计模式）。
        这样的做的好处是进一步降低了CPU的资源消耗。
        缺点是这样做会让程序难以编写，因为请求接受后的处理过程由reactor来决定，使得程序的执行流程难以把握。
        当接受到一个请求后如果涉及到阻塞的操作，这个请求的处理就会停下来去接受另一个请求，程序执行的流程不会像线性程序那样直观。
        twisted框架就是应用这种IO模型的典型例子。
    非阻塞式Coroutine（协程）
        这个模式是为了解决事件驱动模型执行流程不直观的问题，它在本质上也是事件驱动的，加入了 Coroutine 的概念。
"""
"""
与线程/进程的区别
    线程是抢占式的调度，多个线程并行执行，抢占共同的系统资源；
    而微线程是协同式的调度。

    其实 greenlet 不是一种真正的并发机制，而是在同一线程内，在不同函数的执行代码块之间切换，
    实施“你运行一会、我运行一会”，并且在进行切换时必须指定何时切换以及切换到哪。
    greenlet的接口是比较简单易用的，
    但是使用greenlet时的思考方式与其他并发方案存在一定区别：
        1.线程/进程模型在大逻辑上通常从并发角度开始考虑，把能够并行处理的并且值得并行处理的任务分离出来，
            在不同的线程/进程下运行，然后考虑分离过程可能造成哪些互斥、冲突问题，将互斥的资源加锁保护来保证并发处理的正确性。
        2.greenlet则是要求从避免阻塞的角度来进行开发，当出现阻塞时，就显式切换到另一段没有被阻塞的代码段执行，
            直到原先的阻塞状况消失以后，再人工切换回原来的代码段继续处理。因此，greenlet本质是一种合理安排了的串行。
        3.greenlet本质是串行，因此在没有进行显式切换时，代码的其他部分是无法被执行到的，如果要避免代码长时间占用运算资源造成程序假死，
            那么还是要将greenlet与线程/进程机制结合使用（每个线程、进程下都可以建立多个greenlet，但是跨线程/进程时greenlet之间无法切换或通讯）。
"""
